やりたくない事から分類したゲームエンジン考

概要

変更可能性にだけ焦点をあててまとめた。

基本的に「やらないですむならやりたくないクソみたいな努力」をするのがいやなので、そのへんの観点で纏めた。

レイヤー分け

ゲームエンジンに対して、次のレイヤーを定義してみる。

下から積み重なっていくもののようなイメージ。

1.基盤性能確保レイヤー

＝自由度、性能調整性のあるレイヤー。

ゲームランタイムとしてどの程度の性能を求めるか、っていうのを弄れる。

根っこ。

2.構造化機構レイヤー

=構築力、フォーマット維持性を保持してるレイヤー。

フレームワークとしてどの程度追加構造を構成する能力を求めるか、っていう機能があるところ。

3.ゲームエディタレイヤー

=ゲームエディタとしての性能を保持してるレイヤー。

いかに抽象的にゲームのステップを扱えるか、みたいな機能があるところ。

いろいろなものの隠蔽と、それらをコントロールするデザインが必要。

独断と偏見で既存のエンジン数個をこのレイヤー内に置いてみる

レイヤー 1->

レイヤー1までだけだと、構造化を自分でやらないといけなくて、FWのメンテコストを自分が負うことになってつらい。

コードを書く量がメチャメチャ必然的に存在する。

細かいところまで弄れるので、特化させる足がかりとして有用。

要はScaffoldみたいな位置。

このレイヤー1と2の間、1寄りにいるのがCocosシリーズ。

レイヤー 2->

レイヤー2まで備えてると、コードが走るランタイムは隠蔽されている。

書く場所はプラガブルに用意されており、依然としてコードを書く量がかなり必然的に存在する。

が、構造化に対するフォーマットは持っている。のと、そのへんのメンテもゲームエンジン側が負ってくれる。

ゲームエンジンのコード自体は隠蔽されており、変更が不可能な反面、

エンジン自体の制約を守ればアップデートでもクソ面倒くさいことにはなりにくいと思う。

このへんを超えて、次のレイヤー3のちょい手前にいるのがUnity。 

レイヤー 3->

ゲームエディタの域。3までエディタの域を押し進めてくと、いろいろ隠蔽した上でコントロールすることが可能になる。

もちろん2も内包してるので、コード書いてなにやらも可能。

GUI天国。一覧性がコードだらけにくらべたらかなり良いと思う。

このへんにUnrealEngine。

振り分けてみた感想

根っこまで弄れるっていうのは、根っこまで変更した場合、そのメンテコストを負うってことなので、

面倒くさくなるしゲームエンジン自体の更新に際して非互換生むので俺はパス。

ゲームを作って遊ぶ事に専念したい。基礎のメンテナンスに関わりたくない。

コンパイルのある、バイナリになる言語でアプリケーションの背骨が作ってあって、

その他の言語でその上に肉付けができる、っていうのが、区分けが安定するしエンジンのメンテコストを背骨のほうに封印できるので楽。

こちらからは以上です。